Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-038

Text File | 1995-06-07 | 40.6 KB | 1,151 lines | [TEXT/R*ch]

Received-Date: Tue, 21 Jun 1994 14:04:25 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-038
To: [e-mail]
Date: Tue, 21 Jun 1994 14:04:20 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 41

C.S.M.P. Digest             Tue, 21 Jun 94       Volume 3 : Issue 38

Today's Topics:

        CopyBits with PixMap
        Gestalt, SU3.0 & List Manager
        How to tell what kind of drive a volume is?
        Photoshop Plug-in Filters useable with other programs?
        Scheduling Sleep in WaitNextEvent
        What is "Clipping Extension"?
        allocating memory quickly -- how?
        sqrti() [Re: Faster Square Root Algorithm]



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Steven Ragatz)
Subject: CopyBits with PixMap
Date: 5 Jun 1994 09:52:39 GMT
Organization: University of Nevada System Computing Services

I am working through the examples in D. Mark's second Primer book using
Think C/C++ v. 6.xx.  I am trying to use CopyBits to copy a PixMap to a
window.  I think that I have typed the code in correctly and I have
looked at the appropriate header files but things are still wrong.  Here is
the code in question:

#include <Picker.h>
#include <Palette.h>

    #define NIL_POINTER    0L
    WindowPtr    gColorWindow;
    Rect        source, dest;
...
/* Setup rects and stuff */
...
     CopyBits( &((CGrafPtr)gColorWindow)->portPixMap,
          &((CGrafPtr)gColorWindow)->portPixMap,
           &source, &dest, srcCopy, NIL_POINTER );

The error that the compiler gives is:

File RColorTutor.c; Line 305
Error:   first argument to function CopyBits does not match prototype

so... I look up CopyBits and find it to be:

pascal void CopyBits(const BitMap *srcBits,const BitMap *dstBits,const
    Rect *srcRect, const Rect *dstRect,short mode,RgnHandle maskRgn)

I am under the impression that with QD, CopyBits uses PixMaps the same
way as it used to use BitMaps.

I looked up an example that uses a GrafPtr cast instead of a CGrafPtr and
it works as:

    CopyBits (& ((GrafPtr)Port1)->portBits, &((GrafPtr)Port2)->portBits,
          &Rect1, &Rect2, 0, theregion);

so, I am left confused and stumped.  Could anyone tell me where I am
going wrong with my data structures?

-    Steve

+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Sun, 5 Jun 1994 16:19:56 GMT
Organization: Best Before Yesterday

In article <2ss797$[e-mail]>, [e-mail] (Steven
Ragatz) wrote:

> I am working through the examples in D. Mark's second Primer book using
> Think C/C++ v. 6.xx.  I am trying to use CopyBits to copy a PixMap to a
> window.  I think that I have typed the code in correctly and I have
> looked at the appropriate header files but things are still wrong.  Here is
> the code in question:
>
> #include <Picker.h>
> #include <Palette.h>
>
>     #define NIL_POINTER    0L
>     WindowPtr    gColorWindow;
>     Rect        source, dest;
> ...
> /* Setup rects and stuff */
> ...
>      CopyBits( &((CGrafPtr)gColorWindow)->portPixMap,
>           &((CGrafPtr)gColorWindow)->portPixMap,
>            &source, &dest, srcCopy, NIL_POINTER );
>
> The error that the compiler gives is:
>
> File ColorTutor.c; Line 305
> Error:   first argument to function CopyBits does not match prototype
>

Steve,

     Code looks OK: just typecast your portPixMap to a (BitMap *) like
this:

CopyBits ( (BitMap *) ((CGrafPtr)gColorWindow)->portPixMap, ...

     Alex

--
Alex Metcalf, Best Before Yesterday
Mac programmer in C, C++, HyperTalk, assembler
Juggler, 3-ball tricks

Internet:          [e-mail]
Fax (UK):          (0570) 45636
Fax (US / Canada): 011 44 570 45636

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Sun, 5 Jun 1994 16:22:58 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I download a working version of Dave Mark's "ColorTotor" from America
Online, a couple years ago.  It's currently in my floppy archives.
someone else could probably answer your question before I log off, get it,
log on and send you the fragment.

But I was also amazed at the similaritios between that program and one
called "CopyBits" which I got of ftp devtools.symantec.com.  I'd heard
mention of this source in a few conferences, but no one ever said where
to find it.  It's much more sophisticated and has greater scope than
Dave's little ditty.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosen)
Date: 5 Jun 1994 17:30:33 GMT
Organization: Massachusetts Institute of Technology

[Confusion about copybits parameters]

Here's a message I saved from Tim Dierks from quite a while ago, which
explains it very cleary.
--Alex


In article <[e-mail]>, [e-mail] (Jose Raffucci) wrote:
>
>
> I'm really curious about what parameters should actually passed to
> copybits.  IM V and think ref 1.0 say the first two should be address
> of a pixmap or bitmap.  The examples all show :
>
>  CopyBits(&(GrafPtr)->portBits, ...);
>
> In IM VI however (21-19) it says that you can pass it the following:
>
>  pixBase =  GetGWorldPixMap(world);   (pixbase is PixMapHandle)
>  CoypBits( *pixBase, ...);
>
> 1 worlds, and 2 doesn't.  I looked and the addresses returned for 1&2
> are not the same.  close, but not quite.  I've played around with just about
> every way toet the address of the pixmap for 2, and nothing works, and yes,
> I locked my handles.
>
> Why the apparent inconsistency?

CopyBits is definitely the wackiest call in the ToolBox.  It can accept
three different kinds of parameters for its "sourceBits" and "destBits"
arguments:

 - A pointer to a BitMap
 - A pointer to a PixMap
 - A pointer to the spot in a CGrafPort where a BitMap is supposed to be
   if this port were actually a GrafPort

It's got a little song and dance it does to figure out what it's getting,
but that's not important.  The weirdest thing is that you can pass in a
pointer to a PixMap, which is the PixMapHandle dereferenced once.  This
PixMapHandle does not have to be locked; even though CopyBits can move
memory, it won't do so until after it's figured out what kind of
arguments it's getting and recovered the original handle, if necessary.

I don't know if this will help you solve your problem, but it's certainly
entertained me to tell you this.

Tim Dierks
[e-mail]
                  I work for MacDTS, but I speak for myself.
 "If you can't lick 'em, put 'em on with a big piece of tape." -
Negativland




---------------------------

>From [e-mail]
Subject: Gestalt, SU3.0 & List Manager
Date: 4 Jun 94 16:36:53 -0500
Organization: Laurentian University

Does anybody know if there is a Gestalt selector code to see if System Update
3.0 is installed? Specifically, I want to know if the new LDEF used by the
StandardGetFile dialog box is available. (i.e. the one that puts an icon next
to the item name.) Also, I would like to know what format the data should be
in when I pass a handle to LSetCell(sic).

E-mail is preferred, but if you post to the group, that's ok.

--JA
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Sat, 4 Jun 1994 23:18:26 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <[e-mail]> [e-mail] writes:

>Does anybody know if there is a Gestalt selector code to see if System Update
>3.0 is installed? Specifically, I want to know if the new LDEF used by the
>StandardGetFile dialog box is available. (i.e. the one that puts an icon next
>to the item name.)

Call Gestalt with the "gestaltStandardFileAttr" ('stdf') selector and
test the "gestaltStandardFileHasColorIcons" bit (2) in the response.

>Also, I would like to know what format the data should be
>in when I pass a handle to LSetCell(sic).

I don't believe that the format of the data used by the Standard File
LDEF has been documented.  If this is in fact the case, I would
recommend _not_ trying to reverse-engineer the format, as this is
prone to breaking in the future.  Instead, write your own LDEF that
does what you want.  LDEFs aren't very hard to write; I imagine that a
reasonably competent Macintosh programmer could write such an LDEF in
a few hours, if not less.

Chris.


+++++++++++++++++++++++++++

>From Alexander M. Rosenberg <[e-mail]>
Date: Mon, 6 Jun 1994 02:14:33 GMT
Organization: Hackers Anonymous

In article <[e-mail]> Chris Wysocki, [e-mail]
writes:
> I don't believe that the format of the data used by the Standard File
> LDEF has been documented.  If this is in fact the case, I would
> recommend _not_ trying to reverse-engineer the format, as this is
> prone to breaking in the future.  Instead, write your own LDEF that
> does what you want.  LDEFs aren't very hard to write; I imagine that a
> reasonably competent Macintosh programmer could write such an LDEF in
> a few hours, if not less.

I agree with Chris.

DO NOT REVERSE ENGINEER THE SYSTEM SOFTWARE AND USE THAT INFORMATION IN YOUR
APPLICATIONS! WE WILL HUNT YOU DOWN AND KILL YOU.

In this case, I was just speaking with the Software Mercenary responsible for
including the Macintosh Easy Open version of Standard File in System Update
3.0. We were speaking of a way to increase the limit of items that can be
displayed for a given directory. Doing so would specifically break people who
"know" the format of the cell data.
- -------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-                          - nobody cares what I say.       -             -

---------------------------

>From [e-mail] (Matthew Paul Cline)
Subject: How to tell what kind of drive a volume is?
Date: 2 Jun 1994 23:17:36 GMT
Organization: University of California, Santa Cruz


    Is there any sort of system call that will tell you the type
of a volume (flopyy driver, hard drive, or other)?  Thanks in advance.
--
Poodles have no honor.               Have you hugged your shoggoth today?
GE d? -p+ c++(+++) l++ u++ e+ m+ s/- n+(-) h+ f !g w+ t+ r y+

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: 2 Jun 1994 16:59:01 -0700
Organization: California State University San Marcos

Matthew Paul Cline ([e-mail]) wrote:

>    Is there any sort of system call that will tell you the type
>of a volume (flopyy driver, hard drive, or other)?  Thanks in advance.

Not in general, but you can infer a lot about a volume from looking
at a few bits of information.

1) What driver talks to it? Is it '.Sony'? Then it's a floppy.
2) Is the driver in the range for SCSI devices?
3) Is the volume read-only?
4) Is the volume ejectable?
5) Is the volume "remote"?
.. and so on.

None of the information is conclusive, but you can figure out what
you need to know >95% of the time.

Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu


+++++++++++++++++++++++++++

>From [e-mail] (jerry halstead)
Date: 3 Jun 1994 00:45:39 GMT
Organization: University of North Carolina Extended Bulletin Board Service

reply to message from [e-mail]:

I got some help last week correlating between a vRefNum and the actual
SCSI ID.  I used PBHGetVInfo to get the refnum and the following formula
to convert to a SCSI ID:

 HParamBlockRec    volPB;
 volPB.volumeParam.ioVRefNum = 0;
 volPB.volumeParam.ioNamePtr = (StringPtr)name;
 volPB.volumeParam.ioVolIndex = i;   // this is in a loop to get all drivers
if (PBHGetVInfo(&volPB,FALSE) == noErr){
   RefNum = abs(volPB.volumeParam.ioVDRefNum+1);
   scsiID = RefNum-32;  }

I then use the scsiID with the SCSI manager routines to obtain Inquiry data
for the given drive, which includes, among other things, the device type.
Here's the beginnings of the device type table from the SCSI spec:

____SCSI_Dev_types___
direct access (disk) 0
seq access (tape)    1
printer device       2
processor            3
worm                 4
cd-rom               5

Of course this may not be the level of implementation you had in mind.
Hope it helps.


Big head Jerry and the demonstrables....
--
- ----------------------------------------------------------------------------
 \ The above does not represent OIT, UNC-CH, laUNChpad, or its other users. /
   ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Brian Bechtel)
Date: 4 Jun 1994 07:00:36 -0700
Organization: Apple Computer, Inc., Cupertino, California

[e-mail] (Marshall Clow) writes:

>Matthew Paul Cline ([e-mail]) wrote:

>>    Is there any sort of system call that will tell you the type
>>of a volume (flopyy driver, hard drive, or other)?  Thanks in advance.

>Not in general, but you can infer a lot about a volume from looking
>at a few bits of information.

>1) What driver talks to it? Is it '.Sony'? Then it's a floppy.

Or an HD 20.  Or something which is trying to emulate either a floppy or
an HD 20.  (The HD 20 was the first Apple-labeled Macintosh hard drive.
It did not use SCSI.)

>2) Is the driver in the range for SCSI devices?

With Asynchronous SCSI Manager 4.3, SCSI devices have can drivers
outside the traditional range.

>3) Is the volume read-only?
>4) Is the volume ejectable?
>5) Is the volume "remote"?
>.. and so on.

>None of the information is conclusive, but you can figure out what
>you need to know >95% of the time.

Yup.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

+++++++++++++++++++++++++++

>From [e-mail] (David Shayer)
Date: Sun, 5 Jun 1994 22:36:37 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Brian Bechtel ([e-mail]) wrote:
: [e-mail] (Marshall Clow) writes:
: >Matthew Paul Cline ([e-mail]) wrote:
: >>    Is there any sort of system call that will tell you the type
: >>of a volume (flopyy driver, hard drive, or other)?  Thanks in advance.
: >1) What driver talks to it? Is it '.Sony'? Then it's a floppy.
: Or an HD 20.  Or something which is trying to emulate either a floppy or
: an HD 20.  (The HD 20 was the first Apple-labeled Macintosh hard drive.
: It did not use SCSI.)

You can tell a floppy from an HD20 by driver refnum.  The floppy driver
has refnum -5, while the hd20 driver has refnum -2.


+------------------------------------------------------------------------+
|David Shayer                                  [phone]            |
|Sentient Software / Symantec                  [e-mail]|
|"Subvert the Dominant Paradigm."              Applelink: SHAYER         |
+------------------------------------------------------------------------+


---------------------------

>From [e-mail] (Ian Dowell)
Subject: Photoshop Plug-in Filters useable with other programs?
Date: 7 Jun 94 04:35:24 GMT
Organization: Bolt, Beranek and Newman Inc.

Are Photoshop Plug-in Filters useable with other programs?
Is it possible to write a program which could use the filters
to do transformations?
Is there any documentation or example code available?

Thanks in advance!
Ian
--
- ----------------------------------------------------------------------
Ian Dowell            Bolt, Beranek & Newman, Cambridge, MA
[e-mail]       [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Mon, 06 Jun 1994 22:35:41 -0700
Organization: Infinity Systems

In article <[e-mail]>, [e-mail] (Ian Dowell)
wrote:

> Are Photoshop Plug-in Filters useable with other programs?
> Is it possible to write a program which could use the filters
> to do transformations?
> Is there any documentation or example code available?

Photoshop filters, in general, are usable by other programs.  To write such
a program, simply follow the interface given in the Adobe plug-in
specification files (the same ones you need if you're writing plug-ins).
You can find this specification in various places online, including from
anonymous FTP at:

ftp://export.acs.cmu.edu//pub/PSarch/misc-mac/PS2.5Developers_Kit.cpt.hqx

The plug-ins _included_ with Photoshop, however, are not usable by other
programs because of a passwording sceme they use to verify that they are
talking to Photoshop.

_troy
//////// //////___Troy [e-mail]__ //
  //    //       Infinity Systems ; Redmond, Washington                //
 //    //  //  "Insert witty quote here."                             //
//    //////________________________________________________________ //

---------------------------

>From Ken Prehoda <[e-mail]>
Subject: Scheduling Sleep in WaitNextEvent
Date: 4 Jun 1994 02:54:55 GMT
Organization: Univ of Wisc-Madison

I have a number of questions concerning calling WaitNextEvent.

First, it has been mentioned that WaitNextEvent should
only be called about once a second (possibly when
you aren't doing anything).  What is the best way to accomplish
this?

Second, what is the best way to schedule the sleep
parameter?  I can envision four situations that may
require different values for sleep:

1) I'm in the foreground and doing something.

2) I'm in the foreground and doing nothing.

3) I'm in the background doing something.

4) I'm in the background doing nothing.

What are the best values in these situations?

Thanks,
Ken Prehoda
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Fri, 03 Jun 1994 23:38:47 -0500
Organization: One Step Beyond

Ken Prehoda <[e-mail]> wrote:

> I have a number of questions concerning calling WaitNextEvent.
>
> First, it has been mentioned that WaitNextEvent should only be called
> about once a second (possibly when you aren't doing anything).  What
> is the best way to accomplish this?

Not exactly.  When people refered to fixed-time calling of WNE it was in
the context of executing computationally intensive code and still giving
time to other apps.  IOW, being a nice coop multi-tasking app (NCMTA).

When you're not doing anything that's computationally intensive, that is,
you don't need idle time, just give the sleep value something really big.

What will happen is that any time you're app gets a real event such as
a mouse down or an update, WNE will return immediately after the event is
posted (as long as the other apps are NCMTA's) so you can handle it.

If you're app doesn't need to do anything (i.e. there are no events
pending),
then WNE won't bother returning until either 1) the sleepTime has passed or
2) none of the other apps need to do anything either.

To sum up.  The sleep parameter is a _suggestion_ to WNE about how much
time
you need between idle events.  WNE may return before it has elapsed if the
machine is not busy.  It may return after it has elapsed if the machine is
really busy.  The fixed-timing technique for calling WNE is to assure your
app gets a large timeslice when it is executing some critical and intensive
code.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John Norstad)
Date: Fri, 03 Jun 1994 23:11:44 -0500
Organization: Northwestern University

In article <2soqdv$[e-mail]>, Ken Prehoda
<[e-mail]> wrote:

> I have a number of questions concerning calling WaitNextEvent.
>
> First, it has been mentioned that WaitNextEvent should
> only be called about once a second (possibly when
> you aren't doing anything).  What is the best way to accomplish
> this?
>
> Second, what is the best way to schedule the sleep
> parameter?  I can envision four situations that may
> require different values for sleep:
>
> 1) I'm in the foreground and doing something.
>
> 2) I'm in the foreground and doing nothing.
>
> 3) I'm in the background doing something.
>
> 4) I'm in the background doing nothing.
>
> What are the best values in these situations?

These are very good and very difficult questions, and not everyone agrees
on the answers. (I just had a debate about this issue with Leonard
Rosenthol today, in fact.)

Here's what I do, in three different circumstances:

(1) In my main event loop, when my program is idle, I call WNE with sleep
= GetCaretTime(). This gives other non-idle processes plenty of time, and
in the case where I'm in the foreground and my active window includes a
text editing field, it keeps my caret blinking. I also pass a mouseRgn
parameter to WNE in this call, to get woken up immediately if I'm in the
foreground and the user moves the mouse and I need to adjust the cursor.

(2) During CPU-intensive tasks, I call a "GiveTime" function periodically.
This function calls WNE once every five ticks with sleep=0 and
mouseRgn=nil. It handles at least update, activate, suspend, and resume
events. It also checks for user cancel actions (Command-period, Escape,
click on Cancel button in status window, or whatever). It also keep my
animated cursor spinning.

It's important to throttle your WNE calls in this case. Your GiveTime
function should only call WNE every 4-6 ticks (Apple-recommended values).
This avoids excessive process switching (thrashing), gives other
CPU-intensive tasks plenty of time, makes the foreground process
responsive to user actions when you are in the background, doesn't slow
you down noticeable on an otherwise idle system, gives excellent response
to user cancel operations, gives a smoothly animated cursor, and provides
uniform behavior independent of CPU speed. It's a good balance.

You mentioned only calling WNE once per second (60 ticks). That's way too
long - you are really hogging the CPU. 5 ticks is much more appropriate.

(3) When waiting for a network task to complete (e.g., during an
asynchronous MacTCP send or receive call, while I'm polling the result
code in the parameter block), I call WNE continuously with sleep=0 and
mouseRgn=nil. The difference between (2) and (3) is that (3) doesn't
throttle the WNE calls to every 5 ticks. This is because I have nothing to
compute in this case, so I want to yield to other processes immediately to
let them use the available CPU time while I'm waiting. I use the same
GiveTime function as in (2), but I pass a parameter telling it to call WNE
even if the 5 ticks hasn't expired.

Notice that I don't do anything special when I'm in the background - the
algorithm is the same. Some people use a non-zero sleep time when they're
in the backgound doing CPU-intensive tasks. This slows you down quite a
bit, even on an otherwise idle system, and I think it's wrong. The correct
way to yield time to other processes when you are in the background is to
make certain you call WNE at least every 5 ticks, not to use a non-zero
sleep time. Indeed, this is always the correct way to yield time to other
processes, and being in background or in the foreground really doesn't
matter.

As an example, here's my GiveTime function in NewsWatcher:

/*----------------------------------------------------------------------------
   GiveTime

   Give time to other processes during long operations and check for
   user cancels.

   Entry:   waiting = true if waiting for MacTCP or something else.

   Exit:    function result = error code (userCanceledErr if canceled
               by user, else noErr).
- --------------------------------------------------------------------------*/

OSErr GiveTime (Boolean waiting)
{
   EventRecord ev;
   Boolean gotEvt;
   static long nextTime = 0;

   if (!gLongOperation) {
      HiliteMenu(0);
      SpinCursor(0);
      ShowCursor();
      gLongOperation = true;
   }

   if (TickCount() >= nextTime) {
      SpinCursor(16);
      nextTime = TickCount() + 5;
      waiting = true;
   }

   if (waiting) {
      gotEvt = WaitNextEvent(everyEvent, &ev, 0, nil);
      if (gotEvt) HandleEvent(&ev);
   }

   return gCancel ? userCanceledErr : noErr;
}

The "HandleEvent" function is the same event handling function called by
my main event loop.

"gCancel" is a global variable which is set to true by my event handlers
when a user cancel event occurs.

"gLongOperation" is a global variable which records whether I'm busy doing
something or idle. Some of the event handlers need to know this
information.

I hope this is interesting and helps.

--
John Norstad
Academic Computing and Network Services
Northwestern University
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 4 Jun 1994 23:42:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (John Norstad) writes:

>(3) When waiting for a network task to complete (e.g., during an
>asynchronous MacTCP send or receive call, while I'm polling the
result
>code in the parameter block), I call WNE continuously with sleep=0
and
>mouseRgn=nil...

If you're waiting for an asynchronous request to complete with a
completion routine, then you can have the completion routine call
WakeUpProcess using your application's process serial number.  That
way, you can give up more time to other processes and still have your
application awaken when it needs to be awakened.

- Jim Luther


+++++++++++++++++++++++++++

>From [e-mail] (John Norstad)
Date: Sun, 05 Jun 1994 08:48:16 -0500
Organization: Northwestern University

In article <2srhid$[e-mail]>, [e-mail] (Jump
Long) wrote:

> If you're waiting for an asynchronous request to complete with a
> completion routine, then you can have the completion routine call
> WakeUpProcess using your application's process serial number.  That
> way, you can give up more time to other processes and still have your
> application awaken when it needs to be awakened.

But then you can't poll for user cancel events, which is very important
when waiting for long network requests to complete.

--
John Norstad
Academic Computing and Network Services
Northwestern University
[e-mail]

---------------------------

>From Paul Goyette <[e-mail]>
Subject: What is "Clipping Extension"?
Date: 5 Jun 1994 15:17:58 GMT
Organization: (none)

The title says it all - I've installed the Drag&Drop stuff, and when I
reboot the Mac,
I get a message that the Clipping Extension cannot be used because it is
"too new".

So, what is this Cliping Extension, and what version of what program do I
need to
be able to use it?

- ---------------------------------------------------------
Paul Goyette        |  PGP Public key available on request
[e-mail]  |  Fingerprint: 54 03 19 EE 99 57 FB 79
                    |               74 0A D0 E6 BE 84 0E DA
- ---------------------------------------------------------

+++++++++++++++++++++++++++

>From Richard Cardona <[e-mail]>
Date: 5 Jun 1994 17:43:21 GMT
Organization: UT-Austin

In article <2ssqb6$[e-mail]> Paul Goyette, [e-mail]
writes:
>So, what is this Cliping Extension, and what version of what program do I
>need to
>be able to use it?

In System 7.0.x, you need to run Macintosh Drag and Drop and the clipping
extension to have full clipping files support.  What are clipping files?
They are Drag and Drop data the finder can support and create files out
of.  Right now I believe the Finder only supports text, pictures and
sound.  Moovs are in the works.  With the clipping extension, the finder
can even open the clipping files and show you what they contain - neato!
Example, highlight a piece of text from SimpleText and drag it over to
the Finder, release it, and the Finder will create a text clipping file.
You must have the clipping extension to do this.  Similarly, a text
clipping file can be dragged back into Simpletext and "pasted."

In System 7.5,the clipping extension is useless and built in to the
Finder, but you still need the Drag and Drop extension for now.

I suggest you get a copy of both the Drag and Drop extension 1.1 and the
Clipping extension from June's Developer CD.  The documentation is also a
little confusing, claiming you need Finder 7.1.3 also.  (7 Pro's Finder
is 7.1.4)  But, I know this combo works together (at least on a
Powermac).  I don't have an on-line ftp site for the clipping extension,
anyone? The WWDC contains the Drag and Drop extension for 7.5 I don't
recommend this version for use without 7.5.

Rick

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 6 Jun 1994 20:29:54 GMT
Organization: Apple Computer

Paul Goyette, [e-mail] writes:
> So, what is this Cliping Extension, and what version of what program do I
> need to
> be able to use it?

You need Finder 7.1.3 or 7.1.4. (7.1.4 is identical to 7.1.3 except for the
size of a text field in the 'About This Mac' window, to support the
PowerMacs.)

Richard Cardona, [e-mail] writes:
> Right now I believe the Finder only supports text, pictures and
> sound.  Moovs are in the works.

The Finder will make clipping files out of any kind of data an application
can drop, and you can then take those clippings and drop them into another
app. The only type limitations are what kinds of clippings the Finder can
open up and display -- only text and pict, right now.

> I suggest you get a copy of both the Drag and Drop extension 1.1 and the
> Clipping extension from June's Developer CD.

D&D 1.1 is also on the bookmark CD with 'develop' 18. This includes Finder
7.1.3.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

---------------------------

>From [e-mail] (Shawn V. Hernan)
Subject: allocating memory quickly -- how?
Date: 2 Jun 1994 20:28:04 GMT
Organization: The University of Pittsburgh

Greetings all,


     I want to allocate a large array (1000 elements) of pointers to
characters the beginning of a program (it makes sense to do it this way
in this case) . So, in a loop, I have code that looks like the
following:

    array[i][j] = NewPtrClear(80);

    I have a similar Unix and VMS program that uses malloc in the same
way I use NewPtr above. All three programs work pretty well, excpet
that allocating the memory on the Macintosh is VERY SLOOOOOOW. Is there
a faster way to allocate lots of little chunks of memory than NewPtr?
malloc dies a cold death on the Mac, and I don't know why. I've looked
through the faq's with no luck.


       Any help is deeply appreciated.

Thanks,
Shawn




Shawn Valentine Hernan       |Is the War on Drugs worth it?
The University of Pittsburgh |Why does the government want your guns?
[e-mail]           |Does RICO ring a bell?
412-624-6425                 |Did you vote in the last election?

+++++++++++++++++++++++++++

>From [e-mail] (Mike Russell)
Date: Thu, 02 Jun 1994 15:36:06 -0800
Organization: the ag group, inc.

In article <2slfcl$[e-mail]>, [e-mail] (Shawn
V. Hernan) wrote:
>      I want to allocate a large array (1000 elements) of pointers to
> characters the beginning of a program (it makes sense to do it this way
>     array[i][j] = NewPtrClear(80);

try allocating one giant block instead:

 char *p = NewPtrClear(80L * height * width);

then in your loop

 array[i][j] = p + ((long)i * (long)j) * 80L;

As for why - the reason goes back to the original tiny Mac that the
Memory Manager was designed for.  Call it a homage to history.

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: 3 Jun 1994 04:06:01 +0200
Organization: Contributed Software GbR

In article <2slfcl$[e-mail]>,
Shawn V. Hernan <[e-mail]> wrote:

> that allocating the memory on the Macintosh is VERY SLOOOOOOW. Is there
> a faster way to allocate lots of little chunks of memory than NewPtr?

NewHandle might be a little bit faster than NewPtr, depending on how many
relocatable blocks you have in your heap; however, I doubt that the
difference will be very big.

> malloc dies a cold death on the Mac, and I don't know why.

What problems do you have with malloc?

In the program that I'm currently writing, I have to deal with
ten-thousands of very small blocks; at first I used handles for all of
them, because, well, we're on a Mac, and "one uses" handles on a Mac. Later
I have changed all the code to use malloc instead, and some portions of the
program are now more than twice as fast (especially the routines that
allocate lots of blocks). I'm not very happy about the fact that free()
never releases the memory that has been allocated, but speed is more
important for me than that (in this case at least - normally I don't use
malloc in my programs).

________________________________________________________________________
Stefan Kurth                 Berlin, Germany              [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: 04 Jun 1994 23:45:19 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] (Marc Cooperman) writes:
>In my limited experience in mac programming, I read somewhere that the Mac
>memory manager was designed to manage a system with small memory (like 128K
>- remember that). So basically any memory operation can cause the heap to
>be compacted - the mac is trying to optimize memory utilization and
>minimize fragmentation.

  This is true to some extent.  If you use pointers much, you'll get
quite a lot of memory shuffling, because the memory manager tries to
keep all of the non-relocatable blocks together.  If you use handles
instead, and call MaxApplZone() at the beginning of your program,
there won't be too much shuffling going on.

  I should also note that I got some information in the mail a couple
of months ago from a company that makes a replacement for the whole
malloc()/newptr()/newhandle() suite.  I think it's called SmartHeap.
Looked pretty interesting, for programs which need to do a *lot* of
memory allocation.
--
Anton Rang ([e-mail])

+++++++++++++++++++++++++++

>From shawn@greebe ([e-mail])
Date: Mon, 6 Jun 1994 16:43:15 GMT
Organization: HoloNet National Internet Access System: 510-704-1058/modem

Shawn V. Hernan ([e-mail]) wrote:
> malloc dies a cold death on the Mac, and I don't know why. I've looked
> through the faq's with no luck.

Assuming that you are using Think C, the dead malloc may actually be a
problem where you might be overrunning the limits of your allocated
block. In Think C this can corrupt the next structure in such a way that
is frequently locks up the machine at the next memory allocation call
which tries to use this memory. Is it possible that you are trying to
store 80 character strings in those character pointers ? The terminating
null would them blow out the next allocation and cause just this sort
of behavior.

This is a long standing Think C behavior and lots of people have run into
it, not really a bug (you are after all overrunning your allocation),
but quite annoying.

I agree with the original poster about allocation of a single large block
and then assigning the addresses, this is often faster. Think actually uses
a variation of this for malloc.

Shawn Lavin ([e-mail])
As always, my opinions are my own


---------------------------

>From [e-mail] (Brandyn Webb)
Subject: sqrti() [Re: Faster Square Root Algorithm]
Date: 27 May 1994 16:28:39 -0700
Organization: Apple Computer Inc, Cupertino, CA

    Here's the integer sqrt() code I use; it looks similar to
some others posted, but may be a little faster (or slower; who
knows).  Hope someone finds it useful:


#define iterate(e)            \
    y <<= 1;                \
    temp = (y|1)<<(2*e);    \
    if (temp <= X) {        \
        y |= 2;                \
        X -= temp;             \
    }

unsigned sqrti(X)
register unsigned X;
{
    register unsigned yy, y, temp;

    y = 0;
    iterate(15); iterate(14); iterate(13); iterate(12);
    iterate(11); iterate(10); iterate(9); iterate(8);
    iterate(7); iterate(6); iterate(5); iterate(4);
    iterate(3); iterate(2); iterate(1); iterate(0);
    return y>>1;
}


    -Brandyn ([e-mail])


+++++++++++++++++++++++++++

>From [e-mail] (Corrin Lakeland)
Date: 6 Jun 1994 00:55:23 GMT
Organization: SANS, Victoria University of Wellington, New Zealand.

> [Another SQRT routine]

I was just wondering, would it not be faster to set up a log table in
memory and use that for calculating square roots.  Depending on how much
speed and or accuracy you need you could change the table (speed =
greater range, accuricy = more choices).  This should be very fast to
look up if you are doing square roots extensivly - otherwise the memory
use would make it not worth while.

Disclaimer : I have not tested this meathod for speed, while it will
work, it may turn out to be slower or use excessive amounts of ram.

Corrin Lakeland ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 6 Jun 1994 02:51:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2sts5r$[e-mail]>,
[e-mail] (Corrin Lakeland) writes:

>> [Another SQRT routine]
>
>I was just wondering, would it not be faster to set up a log table
in
>memory and use that for calculating square roots.  Depending on how
much
>speed and or accuracy you need you could change the table (speed =
>greater range, accuricy = more choices).  This should be very fast
to
>look up if you are doing square roots extensivly - otherwise the
memory
>use would make it not worth while.
>
>Disclaimer : I have not tested this meathod for speed, while it will

>work, it may turn out to be slower or use excessive amounts of ram.

If you're willing to use a table lookup method, a technique that I
have found to be very fast is to compute a table of square roots and
use entries from it to seed Newton-Raphson.  The trick is to estimate
Log2(N) by finding the topmost set bit of N.  Then use this estimate
to "normalize" N into an index in the lookup table, lookup the value,
and then "denormalize" the value back into the correct range.  Once
you have this estimate, you only need a very small number of
iterations.  For example, a table of 128 values provides initial
seeds accurate enough to compute the square root of a 32-bit integer
in just one iteration of Newton-Raphson.  The same table can be used
to do Fixed or Fract square roots in two iterations each.  If a table
of 128 values is too large then you can reduce the table down to 32
(maybe 16) entries and then do one more iteration of Newton-Raphson.

Jim Lloyd
[e-mail]


---------------------------

End of C.S.M.P. Digest
**********************